PDCP Layer Active Protocol Stack Implementation to Reduce Handover Interruption

ABSTRACT

Apparatus and methods are provided to support dual active protocol stacks (DAPS) to reduce mobility interruption time in communication system. In novel aspect, the PDCP reconfiguration includes reconfiguring a normal PDCP to a DAPS PDCP such that the DAPS PDCP is associated with both the source cell and the target cell, and reconfiguring a DAPS PDCP to the normal PDCP by releasing the association with the source cell. In one embodiment, the PDCP entity receives a PDCP reconfiguration request from upper layers of the UE configured with DAPS establishes a header compression protocol, a ciphering function, and an integrity protection function for the target cell. In one embodiment, the PDCP reconfiguration request triggers the DAPS PDCP to be normal PDCP. The DAPS PDCP releases the source header compression, ciphering and integrity protection functions.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is filed under 35 U.S.C. § 111(a) and is based on andhereby claims priority under 35 U.S.C. § 120 and § 365(c) fromInternational Application No. PCT/CN2019/095059, titled “APPARATUS ANDMETHOD OVER PDCP LAYER TO REALIZE DUAL ACTIVE PROTOCOL STACK TO REDUCEHANDOVER INTERRUPTION,” with an international filing date of Jul. 8,2019, and from International Application No. PCT/CN2019/095854, titled“APPARATUS AND METHOD TO CONTROL MOBILITY PROCEDURE TO REDUCE HANDOVERINTERRUPTION”, with an international filing date of Jul. 12, 2019. Thisapplication claims priority under 35 U.S.C. § 119 from ChineseApplication Number CN 202010574767.0 titled “PDCP LAYER ACTIVE PROTOCOLSTACK IMPLEMENTATION TO REDUCE HANDOVER INTERRUPTION” filed on Jun. 22,2020, and Chinese Application Number CN 202010580424.5 titled “PDCPLAYER ACTIVE PROTOCOL STACK IMPLEMENTATION TO REDUCE HANDOVERINTERRUPTION” filed on Jun. 23, 2020. The disclosure of each of theforegoing documents is incorporated herein by reference.

TECHNICAL FIELD

The disclosed embodiments relate generally to wireless communication,and, more particularly, to reduce mobility interruption time throughdual protocol stacks in the new radio access system.

BACKGROUND

5G radio access technology will be a key component of the modern accessnetwork. It will address high traffic growth and increasing demand forhigh-bandwidth connectivity. It will also support massive numbers ofconnected devices and meet the real-time, high-reliability communicationneeds of mission-critical applications. Both the standalone NRdeployment and non-standalone NR with LTE/eLTE deployment will beconsidered. In order to improve the UE experience quality, it'sdesirable to reduce the mobility interruption time during handover.Mobility interruption time means the shortest time duration supported bythe system during which a user terminal cannot exchange user planepackets with any base station during transitions. The target formobility interruption time should be 0 ms or close to 0 ms, which isintended for both intra-frequency and inter-frequency mobility forintra-NR mobility.

In the current LTE system, the latency during handover execution isnearly 50 ms, which cannot satisfy the mobility interruption requirementin the NR system. Solutions, such as RACH-less handover andmake-before-break procedures, are proposed to reduce the mobilityinterruption. Though the handover interruption with these solutions canbe reduced, the interruption due to random access procedure anddelivering of signal messages cannot be avoided. These solutions alonecannot meet the latency requirements.

Improvements and enhancements are required to reduce mobilityinterruption with dual protocol stack to zero or close to zero.

SUMMARY

Apparatus and methods are provided to support dual active protocolstacks (DAPS) to reduce mobility interruption time in both LTE and NRsystem. In novel aspect, the PDCP reconfiguration includes reconfiguringa normal PDCP to an DAPS PDCP for a DAPS bearer such that the DAPS PDCPis associated with both the source cell and the target cell, andreconfiguring an DAPS PDCP to the a normal PDCP by releasing theassociation with the source cell. In one embodiment, the PDCP entityreceives a PDCP reconfiguration request from upper layers of the UE,wherein the UE is connected with a source cell in the wireless network,and wherein the UE is configured with DAPS associated with the sourcecell and a data radio bearer for a target cell, establishes a headercompression protocol and applying a header compression configurationprovided by upper layers for the target cell, a cipher function andapplying a cipher algorithm and key provided by upper layers for thetarget cell, and establishes an integrity protection function andapplying an integrity protection algorithm and key provided by upperlayers for the target cell. In one embodiment, the PDCP reconfigurationrequest is triggered by receiving a handover command with a DAPSconfiguration flag dapsConfig. 1 n another embodiment, the PDCP entityswitches header compression, integrity protection and cipher functionsassociated to the source cell to header compression, integrityprotection and cipher functions associated to the target cell uponreceiving a switching request from lower layers. In yet anotherembodiment, lower layers send the switching request upon receiving afirst UL grant from the target cell. In one embodiment, the PDCP entityupon PDCP reconfiguration enables the PDCP reordering and reordering thepackets received from both of the lower layers associated to the sourcecell and the target cell, wherein the on-going PDCP reordering procedureis not interrupted and t-Reordering keeps as it is if the PDCPreordering function is used before the receiving PDCP entity isextended. In one embodiment, the PDCP reconfiguration involvesestablishing a header decompression protocol and applying a headerdecompression configuration provided by upper layers for the targetcell, establishing a decipher function and applying a cipher algorithmand key provided by upper layers for the target cell. The PDCPreconfiguration enables a PDCP reordering and reordering packetsreceived from lower layers associated to the source cell and the targetcell.

In one embodiment, the PDCP reconfiguration request triggers the DAPSPDCP to be changed to normal PDCP. The PDCP entity receives a PDCPreconfiguration request from upper layers of the UE, wherein the UE isconfigured with a DAPS associated with a source cell and a target cell,and wherein a radio link control (RLC) entity associated with the PDCPentity is released for a radio bearer, releases a header compressionprotocol associated with the released RLC entity, releases a cipherfunction associated with the released RLC entity for the radio bearer,and releases a header compression protocol associated with the releasedRLC entity for the radio bearer. In one embodiment, the released RLCentity is associated with the source cell. In another embodiment, thePDCP entity further releases a header decompression protocol associatedwith the released RLC entity, a decipher function associated with thereleased RLC entity for the radio bearer, and a header decompressionprotocol associate with the released RLC entity for the radio bearer. Inyet another embodiment, the PDCP entity stops and resets t-Reorderingwhen configured.

In another novel aspect, upon detecting a DAPS indication flagindicating to maintain a u-plane (UP) protocol of a source cell with asource MAC entity while performing handover to a target cell, the UEcreates a target MAC entity for the target cell, reconfigures a radiolink control (RLC) entity to associate with data radio bearers (DRBs) ofthe target cell, and reconfigures a packet data convergence protocol(PDCP) entity to associate with the RLC entity associated with thetarget cell. In one embodiment, DAPS flag is detected when receiving atleast one indication comprising a dapsConfig flag carried bymobilityControlInfo and a spCellConfig with reconfigurationWithSync. Inanother embodiment, the created MAC entity is a master cell group (MCG)MAC entity, and wherein the UE maintains a source MCG MAC entity and atarget MCG MAC entity. In yet another embodiment, the PDCP entity isreconfigured to establish a target header compression and a headerdecompression protocol to apply a header compression and decompressionconfiguration for the target cell, a target cipher function to apply acipher algorithm and key provided for the target cell, and a targetintegrity protection function to perform integrity protection andintegrity verification for the target cell. In one embodiment,parameters for the target header compression are included inpdcp-Config, which is extended to provide the header compressionparameters for the target cell. In another embodiment, the PDCP entityis reconfigured to process all configured DRBs with pdcp-Config that areestablished, and wherein the PDCP entity is reconfigured to associatewith the target RLC entity and an associated logical channel for allthose DRBs. In one embodiment, PDCP entity is reconfigured to associatewith DRBs when a dapsConfig is configured, and wherein the PDCP entityis reconfigured to associate with the target RLC entity and anassociated logical channel for all those DRBs. In another embodiment,the dapsConfig is provided in pdcp-Config. In one embodiment, the UEfurther associates the target RLC entity and logical channels with thereconfigured PDCP entity with a same drb-Identity value. In anotherembodiment, the UE associates the target RLC entity and logical channelwith target keys and algorithm provided by a reconfiguration message andassociates the target RLC entity and logical channel with a targetheader compression protocol for each DRB. In one embodiment, the UEreleases the source MAC entity and a connection with the source cellupon receiving a DAPS source release indication e.g. daps-SourceRelease.In another embodiment, the UE releases the RLC entities and theassociated logical channels of the source cell and reconfigures the DAPSPDCP entities to normal PDCP entities.

This summary does not purport to define the invention. The invention isdefined by the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, where like numerals indicate like components,illustrate embodiments of the invention.

FIG. 1 is a schematic system diagram illustrating an exemplary wirelessnetwork for mobility interruption reduction with dual-stack inaccordance with embodiments of the current invention.

FIG. 2 illustrates an exemplary NR wireless system with centralizationof the upper layers of the NR radio stacks in accordance withembodiments of the current invention.

FIG. 3 illustrates exemplary NR wireless system supporting inter gNBmobility scenario in accordance with embodiments of the currentinvention.

FIG. 4 illustrates an exemplary transition diagram between the normalreceiving PDCP entity and the DAPS receiving PDCP entity in accordancewith embodiments of the current invention.

FIG. 5 illustrates an exemplary transition diagram between the normaltransmitting PDCP entity and the DAPS transmitting PDCP entity inaccordance with embodiments of the current invention.

FIG. 6 illustrates an exemplary RRC procedure of PDCP reconfigurationfor the change between normal and DAPS PDCP when performing HO with dualactive protocol stacks in accordance with embodiments of the currentinvention.

FIG. 7 illustrates an exemplary diagram of PDCP entity reconfigurationwith change from normal PDCP to DAPS PDCP (PDCP extended) and changefrom DAPS PDCP to normal PDCP (PDCP restoration) procedures inaccordance with embodiments of the current invention.

FIG. 8 illustrates exemplary flow charts for PDCP reconfiguration to theDAPS PDCP in accordance with embodiments of the current invention.

FIG. 9 illustrates exemplary flow charts for PDCP reconfiguration tochange from DAPS PDCP to normal PDCP in accordance with embodiments ofthe current invention.

FIG. 10 illustrates an exemplary RRC procedure when performing HO withDAPS in accordance with embodiments of the current invention.

FIG. 11 illustrates exemplary flow charts to reconfigure the PDCP entityfor all established DRBs or only for DRBs if the dapsConfig is set inaccordance with embodiments of the current invention.

FIG. 12 illustrates exemplary flow charts to reconfigure the RLC entityin accordance with embodiments of the current invention.

FIG. 13 shows an exemplary RRC procedure diagram to maintain two sets ofsecurity keys for both source cell and the target cell during HO inaccordance with embodiments of the current invention.

FIG. 14 illustrates an exemplary RRC procedure to release the connectionwith the source cell after HO is successfully completed in accordancewith embodiments of the current invention.

FIG. 15 illustrates an exemplary flow chart of a PDCP reconfiguration tochange the normal PDCP to DAPS PDCP in in accordance with embodiments ofthe current invention.

FIG. 16 illustrates an exemplary flow chart of a PDCP reconfiguration tochange the DAPS PDCP to normal PDCP in accordance with embodiments ofthe current invention.

FIG. 17 illustrates an exemplary flow chart of a RRC reconfiguration inDAPS in accordance with embodiments of the current invention.

DETAILED DESCRIPTION

Reference will now be made in detail to some embodiments of theinvention, examples of which are illustrated in the accompanyingdrawings.

FIG. 1 is a schematic system diagram illustrating an exemplary wirelessnetwork (system) 100 for mobility interruption reduction with dual-stackin accordance with embodiments of the current invention. Wireless system100 includes one or more fixed base infrastructure units forming anetwork distributed over a geographical region. The base infrastructureunit may also be referred to as an access point, an access terminal, abase station, a Node-B, an eNode-B, a gNB, or by other terminology usedin the art. The network can be homogeneous network or heterogeneousnetwork, which can be deployed with the same frequency or differentfrequency. gNB 101 and gNB 102 are base stations in the NR network, theserving area of which may or may not overlap with each other. As anexample, user equipment (UE) 105 or mobile station 105 is only in theservice area of gNB 101 and connected with gNB 101. UE 105 is connectedwith gNB 101 only. Similarly, UE 106 is only in the service area of gNB102 and connected with gNB 102. UE 106 is connected with gNB 102 only.gNB 101 is connected with gNB 102 via Xnr interface 109. UE 103 is inthe overlapping service area of gNB 101 and gNB 102. In one embodiment,UE 103 is configured with dual protocol stacks and can be connected withgNB 101 and gNB 102 simultaneously.

FIG. 1 further shows simplified block diagrams of gNB 102 and mobilestation/UE 103 in accordance with the current invention. gNB 102 has anantenna 156, which transmits and receives radio signals. An RFtransceiver circuit 153, coupled with the antenna, receives RF signalsfrom antenna 156, converts them to baseband signals, and sends them toprocessor 152. RF transceiver 153 also converts received basebandsignals from processor 152, converts them to RF signals, and sends outto antenna 156. Processor 152 processes the received baseband signalsand invokes different functional modules to perform features in gNB 102.Memory 151 stores program instructions and data 154 to control theoperations of gNB 102. gNB 102 has a protocol stack 171. gNB 102 alsoincludes a set of control modules 155 that carry out functional tasks tocommunicate with mobile stations.

UE 103 has an antenna 135, which transmits and receives radio signals.An RF transceiver circuit 163, coupled with the antenna, receives RFsignals from antenna 135, converts them to baseband signals, and sendsthem to processor 162. In one embodiment, the RF transceiver maycomprise two RF modules (not shown). A first RF module is used for HFtransmitting and receiving, and the other RF module is used fordifferent frequency bands transmitting and receiving which is differentfrom the HF transceiver. RF transceiver 163 also converts receivedbaseband signals from processor 162, converts them to RF signals, andsends out to antenna 135. Processor 162 processes the received basebandsignals and invokes different functional modules to perform features inUE 103. Memory 161 stores program instructions and data 164 to controlthe operations of UE 103. Antenna 135 sends uplink transmission andreceives downlink transmissions to/from antenna 156 of gNB 102. Mobilestation 103 also includes a protocol stack-1 133 and a protocol stack-2134. Protocol stack 133 and 134 includes lower layers and upper layers.In one embodiment, the upper layers include SDAP layer and TCP/IP layerfor data and RRC layer for the control plane. In one embodiment, thelower layers include MAC layer.

Mobile station 103 also includes a set of control modules that carry outfunctional tasks. These control modules can be implemented by circuits,software, firmware, or a combination of them. A PDCPentity/control/module 191 receives a PDCP reconfiguration request fromupper layers of the UE, wherein the UE is connected with a source cellin the wireless network, and wherein the UE is configured with a dualactive protocol stack (DAPS) associated with the source cell and a dataradio bearer for a target cell. A PDCP DAPS reconfigurationentity/module 192 establishes a header compression protocol and appliesa header compression configuration provided by upper layers for thetarget cell, establishes a cipher function and applies a cipheralgorithm and key provided by upper layers for the target cell, andestablishes an integrity protection function and applies an integrityprotection algorithm and key provided by upper layers for the targetcell. A RRC DAPS reconfiguration 193 detects a DAPS flag indicating tomaintain a user plane (UP) protocol of a source cell while performinghandover to a target cell in the wireless network, creates a target MACentity for the target cell, establishes a target radio link control(RLC) entity associated with the target cell, reconfiguring a packetdata convergence protocol (PDCP) entity as DAPS PDCP entity, andreconfigures the PDCP entity to associate with the RLC entity of thetarget cell.

FIG. 2 illustrates an exemplary NR wireless system with centralizedupper layers of the NR radio interface stacks in accordance withembodiments of the current invention. Different protocol split optionsbetween central unit and lower layers of gNB nodes may be possible. Thefunctional split between the central unit and lower layers of gNB nodesmay depend on the transport layer. Low performance transport between theCentral Unit and lower layers of gNB nodes can enable the higherprotocol layers of the NR radio stacks to be supported in the CentralUnit, since the higher protocol layers have lower performancerequirements on the transport layer in terms of bandwidth, delay,synchronization and jitter. In one embodiment, SDAP and PDCP layer arelocated in the central unit, while RLC, MAC and PHY layers are locatedin the distributed unit. A Core unit 201 is connected with one centralunit 211 with gNB upper layer 252. In one embodiment, gNB upper layer252 includes the PDCP layer and optionally the SDAP layer. Central unit211 is connected with distributed units 221, 222, and 223. Distributedunits 221, 222, and 223 each corresponds to a cell 231, 232, and 233,respectively. The distributed units, such as 221, 222 and 223 includesgNB lower layers 251. In one embodiment, gNB lower layers 251 includethe PHY, MAC and the RLC layers.

FIG. 3 illustrates exemplary NR wireless system supporting inter gNBmobility scenario in accordance with embodiments of the currentinvention. The intra-RAT handover is normally based on Xn-basedhandover. HO is performed between gNBs through Xn interface, which areconnected to the NR core network. Each gNB has the protocol stacksincluding SDAP, PDCP, RLC, MAC and PHY layers. A gNB 311 and a gNB 312are both 5G gNBs with a protocol stack 351 and 352, respectively. gNB311 and gNB 312 connects with the Core 301 via NG connection. gNB 311and gNB 312 connect with each other via Xn interface. Protocol stacks351 and 352 includes PHY, MAC, RLC, PDCP and optionally SDAP.

In one novel aspect, two types of PDCP entities are used. One is thenormal PDCP and the other one is the extended PDCP or DAPS PDCP. TheDAPS PDCP entity is either the transmitting PDCP entity or the receivingPDCP entity, which is extended to perform more functions based on thenormal PDCP entity. The DAPS PDCP entity can perform datatransmission/reception simultaneously with the peer PDCP entities ofboth the source cell and the target cell. A UE supports both the normalPDCP entity and the DAPS PDCP entity and reconfigures the PDCP entityfrom the normal PDCP entity to the DAPS PDCP and vice versa based onDAPS reconfiguration indications or messages detected.

In another novel aspect, The UE detects a DAPS indication, such as a HOcommand with a dapsConfig flag indicating that the UE needs to performsimultaneous transmission/reception with both the source cell and thetarget cell during the HO procedure. Therefore, UE needs to continuedata transmission/reception with the source cell when performing randomaccess with the target cell. Upon reception of the HO command, UE keepsthe UP protocol for the source cell. The UE does not reset the mastercell group (MCG) MAC entity for the source cell. For the source cell,The UE does not re-establish PDCP for the DRBs and does not re-establishRLC for the DRBs. For the target cell, the UE creates a target MACentity and establishes RLC entity for the target cell.

In one novel aspect, the UE reconfigures the normal PDCP to DAPS PDCP.In one embodiment, the DAPS PDCP entity includes both DAPS PDCPtransmitting entity and DAPS PDCP receiving entity. It includes twosecurity handling modules and can perform integrityprotection/verification separately for the source cell and the targetcell. In another embodiment, it includes two ciphering modules and canperform ciphering/deciphering separately for the source cell and thetarget cell. In another embodiment, the DAPS PDCP entity furtherincludes two header compression modules and can perform headercompression/decompression separately for the source cell and the targetcell.

FIG. 4 illustrates an exemplary transition diagram between the normalreceiving PDCP entity and the DAPS receiving PDCP entity in accordancewith embodiments of the current invention. A normal receiving PDCPentity 410 of a UE 401 receives data from lower layers of the UE. Atstep 416, normal receiving PDCP entity 410 removes PDCP header. If thereceived packets are not associated with a PDCP service data unit (SDU),at step 419, the data packets are sent to the header decompression unit,otherwise, deciphering and security functions are performed before sentto the header decompression at step 418. At step 415, normal receivingPDCP entity 410 performs deciphering using deciphering keys associatedwith the source cell. At step 414, the normal receiving PDCP entity 410performs integrity verification with the source security key.Optionally, at step 413, a u-plane only reordering is performed. At step412, the u-plane only header or uplink data compression (UDC)decompression is performed. At step 411, the data are in-order deliveredwith duplication detection to the application layer of UE 401.

A DAPS receiving PDCP entity 420 of the UE 401 receives data from lowerlayers of the UE. The data packets come from both the source cell andthe target cell. At step 426, the DAPS receiving PDCP entity 420 removesPDCP header. If the received packets are not associated with a PDCPservice data unit (SDU), at step 429, the data packets are sent to thein-order-delivery procedure, otherwise, deciphering and securityfunctions are performed before sent to the source header decompressionfor source data packets at step 428 or to the target headerdecompression for target data packets at step 438. At step 425,deciphering using source deciphering keys associated with the sourcecell is performed for the source data packets. At step 435, decipheringusing target deciphering keys associated with the target cell isperformed for the target data packets. At step 424, integrityverification with the source security key is performed for the sourcedata packets. At step 434, integrity verification with the targetsecurity key is performed for the target data packets. At step 423, au-plane only reordering is performed. At step 422, the u-plane onlyheader or UDC decompression is performed for the source packets. At step432, the u-plane only header or UDC decompression is performed for thetarget packets. At step 421, the data are in-order delivered withduplication detection to the application layer of UE 401.

In one embodiment, the normal receiving PDCP entity 410 is reconfiguredto the DAPS receiving PDCP entity 420, at step 481, upon receivingreconfiguration indication/message and the DAPS is configured. Inanother embodiment, the DAPS receiving PDCP entity 420 is reconfiguredto the normal receiving PDCP entity 410, at step 482, upon receivingreconfiguration indication/message and the RLC entity associated withthe DAPS receiving PDCP entity is released for a radio bearer.

FIG. 5 illustrates an exemplary transition diagram between the normaltransmitting PDCP entity and the DAPS transmitting PDCP entity inaccordance with embodiments of the current invention. A normaltransmitting PDCP entity 510 of a UE 501 receives data from upper layersof the UE. At step 511, sequence numbering (SN) is performed. At step512, u-plane only header compression is performed. If the receivedpackets are not associated with a PDCP SDU, at step 519, the datapackets are sent to adding PDCP header procedure, otherwise, at step518, ciphering and security functions are performed before sent to theadding PDCP header. At step 514, integrity protection is performed. Atstep 515, ciphering is performed. At step 516, PDCP header is added.

A DAPS transmitting PDCP entity 520 of the UE 501 receives data fromupper layers of the UE. At step 521, sequence numbering (SN) isperformed. At step 522 and step 532, u-plane only header compression isperformed for source data packets and target data packets, respectively.If the received packets are not associated with a PDCP SDU, at step 529,the data packets are sent to adding PDCP header procedure, otherwise, atstep 528 and step 538, ciphering and security functions are performedbefore sent to the adding PDCP header. At step 524, integrity protectionis performed for the source data packets. At step 534, integrityprotection is performed for the target data packets. At step 525,ciphering is performed for the source data packets. At step 535,ciphering is performed for the target data packets. At step 526, PDCPheader is added. At step 527, routing is performed.

In one embodiment, the normal transmitting PDCP entity 510 isreconfigured to the DAPS transmitting PDCP entity 520, at step 581, uponreceiving reconfiguration indication/message and the DAPS is configured.In another embodiment, the DAPS transmitting PDCP entity 520 isreconfigured to the normal transmitting PDCP entity 510, at step 582,upon receiving reconfiguration indication/message and the RLC entityassociated with the DAPS transmitting PDCP entity is released for aradio bearer.

FIG. 6 illustrates an exemplary RRC procedure to control PDCPreconfiguration for the change between normal and DAPS PDCP whenperforming HO with dual active protocol stacks in accordance withembodiments of the current invention. In one novel aspect, the PDCPreconfiguration, including reconfiguring from the normal PDCP entity tothe DAPS PDCP entity and vice versa, is performed upon detecting PDCPreconfiguration indication or message. In one embodiment, the PDCPreconfiguration indication is the handover command with dapsConfig flagfor reconfiguring to the DAPS PDCP entity, or RRCReconfiguration messagewith source cell release, e.g. daps-SourceRelease, for reconfiguring tothe normal PDCP entity.

Upon reception of the HO command with any DAB configured with dapsConfigflag at step 601, the RRC layer requests PDCP layer to perform PDCPreconfiguration to change the normal PDCP to DAPS PDCP at step 610. Inone embodiment, both the transmitting PDCP entity 611 and the receivingPDCP entity 612 are changed from normal to DAPS PDCP). Upon reception ofRRC reconfiguration message to release the source cell at step 602, theRRC layer requests PDCP layer to perform PDCP reconfiguration to changethe DAPS PDCP to normal PDCP at step 620. Both the transmitting PDCPentity 621 and the receiving PDCP entity 622 are changed from DAPS PDCPto the normal PDCP entity. In one embodiment, if the transmitting PDCPentity is changed upon reception of the HO command with dapsConfig flag,the UE switches to use the integrity protection function, cipherfunction and the header compression function corresponding to the targetcell upon reception of the first UL grant of the target cell.

FIG. 7 illustrates an exemplary diagram of PDCP entity reconfigurationwith change from normal PDCP to DAPS PDCP (PDCP extended) and changefrom DAPS PDCP to normal PDCP (PDCP restoration) procedures inaccordance with embodiments of the current invention. In one novelaspect, PDCP entity is reconfigured for the DAPS. At step 701, PDCPreconfiguration request is received by the PDCP entity. The PDCPreconfiguration request can be a request to reconfigure the normal PDCPto the DAPS PDCP at step 710. Normal PDCP is changed to DAPS PDCP fortransmitting PDCP entity at step 711 and receiving PDCP entity at step712 to establish header compression, ciphering and integrity protectionfunction for the target cell, each applying the established function forciphering/deciphering, compression/decompression, and integrityprotection/verification. The PDCP reconfiguration request can be arequest to reconfigure the PDCP to the normal PDCP by releasing thesource cell at step 720. DAPS PDCP is changed to normal PDCP fortransmitting PDCP entity at step 721 and receiving PDCP entity at step722.

FIG. 8 illustrates exemplary flow charts for PDCP reconfiguration forthe change from normal to DAPS PDCP in accordance with embodiments ofthe current invention. When the PDCP entity reconfiguration indicationis received at step 801, the PDCP performs PDCP reconfiguration tochange the normal PDCP to the DAPS PDCP. It is associated with thetarget cell for both downlink (DL) receiving PDCP and uplink (UL)transmitting PDCP. In one embodiment when upper layer request PDCPreconfiguration to change the normal PDCP to DAPS PDCP, the receivingPDCP entity continues to process the PDCP data protocol data units(PDUs) that are received from lower layers associated to the source cellas normal. The transmitting PDCP entity continues the process of thePDCP SDUs received from the upper layer as normal and transmits the PDCPdata PDUs to the source cell. At step 811, the header compressionprotocol for the target cell is created/established as the configurationprovided by upper layer. At step 812, the ciphering algorithm and keyprovided by upper layers for the target cell (if configured) is appliedduring the PDCP reconfiguration procedure. At step 813, the integrityprotection algorithm and key provided by upper layers for the targetcell (if configured) is applied during the PDCP reconfigurationprocedure. Subsequently, the PDCP reordering function to reorder thepackets received from both the lower layers of the source cell and thetarget cell is enabled. In one embodiment, if the reordering function isused before the PDCP entity is reconfigured, the on-going PDCPreordering procedure is not interrupted and a timer t-Reordering keepsas it is. And The DAPS PDCP entity switches to the target cellfunctions, including the compression, ciphering and integrityprotection, upon receiving the first UL grant from the target cell.

FIG. 9 illustrates exemplary flow charts for PDCP reconfiguration tochange the DAPS PDCP to normal PDCP in accordance with embodiments ofthe current invention. When the PDCP entity reconfiguration indicationis received at step 901, the PDCP performs PDCP reconfiguration tochange the DAPS PDCP to normal PDCP. In one embodiment for the PDCPentity reconfiguration to change the DAPS PDCP to normal PDCP, whenupper layers request a PDCP entity reconfiguration, the receiving PDCPentity continues to process the PDCP data PDUs that are received fromlower layers associated to the target cell as normal. The transmittingPDCP entity continues to process the PDCP SDUs received from the upperlayer as normal and transmitted the PDCP data PDUs to the target cell.At step 911, the header compression protocol for the source cell isreleased. At step 912, the ciphering algorithm and key for the sourcecell is released and the ciphering module of the source cell is removed.At step 913, the integrity protection algorithm and key of the sourcecell is released, and the integrity protection module of the source cellis removed. In one embodiment, PDCP status report is triggered and thePDCP status report is sent to the target cell. In one embodiment, if thereceiving PDCP entity is reconfigured to the normal PDCP while thereordering function is configured, the PDCP stops and resetst-Reordering. In another embodiment, if the receiving PDCP isreconfigured to normal PDP while reordering function is not configured,the PDCP disables the reordering function during the reconfigurationprocedure.

In one novel aspect, the UE detects DAPS flag indication requesting tomaintain a user-place (u-plane) protocol of source cell with a sourceMAC entity while performing handover to a target cell. To reduce thehandover interruption, the UE creates a target MAC entity for the targetcell and reconfigures the RLC entity and the PDCP entity for the targetDRBs.

FIG. 10 illustrates an exemplary RRC procedure when performing HO withDAPS in accordance with embodiments of the current invention. At step1001, a DAPS indication is detected. The DAPS indication can be anindication to change the normal PDCP entity to DAPS PDCP entity. ForDAPS indication for reconfiguration for extended PDCP, the DAPSindication or the message indicates that UE needs to performsimultaneous transmission/reception with both the source cell and thetarget cell during the HO procedure. Therefore, UE needs to continuedata transmission/reception with the source cell when performing randomaccess with the target cell. The DAPS indication can be one or more ofthe exemplary indications:

-   -   HO command includes a flag, such as dapsConfig.    -   RRCReconfig message with reconfigurationWithSync.    -   RRCConnectionReconfiguration message with mobilityControlInfo.    -   Flag dapsConfig is carried by mobilityControlInfo.    -   spCellConfig with reconfigurationWithSync

Upon detecting the DAPS indication, UE keeps the UP protocol for thesource cell. The UE does not reset the MCG MAC entity for the sourcecell, does not re-establish PDCP for the DRBs of the source cell anddoes not re-establish RLC for the DRBs of the source cell. At step 1002,the UE creates a MAC entity for the target cell. In one embodiment, theMAC entity created for the target cell is also an MCG MAC entity. The UEhas two MAC entities for the source cell and the target cell,respectively. At step 1003, the UE reconfigures the PDCP entities toinclude more PDCP functions. The normal type of PDCP entity is changedto the DAPS PDCP entity. In one embodiment, UE reconfigures/modifies thePDCP entities for all the DRBs established. In another embodiment, UEreconfigures/modifies the PDCP entities for the DRBs if the dapsConfigis set. In one embodiment, The PDCP parameters for the DAPS PDCP entityis provided by pdcp-Config, which is extended to include the requiredparameters for the target cell. At step 1004, the UE establishesadditional RLC entities (and associated logical channels) for the DRBsand associates the RLC entities (and associated logical channels) to thecorresponding DAPS PDCP entity. In one embodiment, UE establishes RLCentities for all the DRBs established. In one embodiment, UE onlyestablishes RLC entities for the DRBs for which dapsConfig is set. Atstep 1005, the UE derives the keys of the target cell. At step 1006, theUE configures the DAPS PDCP entity to apply the new keys of the targetcell for the data transmission/reception to/from the target cell andcontinues to use the old keys of the source cell for datatransmission/reception to/from the source cell.

FIG. 11 illustrates exemplary flow charts to reconfigure the PDCP entityfor all established DRBs or only for DRBs if the dapsConfig is set inaccordance with embodiments of the current invention. In one embodiment(1110), UE reconfigures/modifies the PDCP entities for all the DRBsestablished. In another embodiment (1120), the UE reconfigures/modifiesthe PDCP entities for the DRBs if the dapsConfig is set. For embodiment1110, at step 1111, the UE considers all established DRBs. At step 1112,the UE reconfigures the PDCP entities for all the DRBs configured withDAPS indication. At step 1113, the UE establishes a new MCG RLC entityand an associated dedicated traffic channel (DTCH) logical channel forall DRBs. At step 1114, the UE associates these RLC entities with theDAPS PDCP entities with the same value of drb-Identity within thecurrent UE configuration.

For embodiment 1120, UE reconfigures the PDCP entities for the DRBs ifthe dapsConfig is set for the DRB. At step 1121, the UE considers eachDRB with the dapsConfig flag, each DRB is identified by the drb-Identityin the drb-ToAddModList provided by the network. At step 1122, the UEchecks if the dapsConfig is set for each DRB. For DRBaddition/modification, for each drb-Identity value included in thedrb-ToAddModList that is part of the current UE configuration, if thedapsConfig is set, the UE determines whether the dapsConfig flag is setfor the corresponding DRB. If the dapsConfig flag is set, at step 1123,the PDCP entity of this DRB performs PDCP reconfiguration procedure tochange the normal PDCP to DAPS PDCP. If step 1122 determines no, theDAPS PDCP is not reconfigured for the corresponding DRB.

FIG. 12 illustrates exemplary flow charts to reconfigure the RLC entityin accordance with embodiments of the current invention. At step 1201,the UE checks each RLC-BearerConfig received in therlc-BearerToAddModList IE. At step 1202, the UE determines whether anRLC bearer with the received logicalChannelIdentity is currentlyconfigured by the UE. If step 1202 determines yes, no RLCreconfiguration is performed. If step 1202 determines no, at step 1211,the UE establishes an RLC entity in accordance with the receivedrlc-Config. At step 1212, the UE configures a MAC entity with a logicalchannel in accordance to the received mac-LogicalChannelConfig. At step1213, the UE associates this logical channel with the DAPS PDCP entityidentified by servedRadioBearer. In one embodiment, drb-Identity ofservedRadioBearer is identical to the drb-Identity value in thedrb-ToAddModList with dapsConfig configured. In one embodiment, the UEassociates this logical channel with the keys/algorithm provided by theHO command and the new header compression protocol in the DAPS PDCPentity identified by servedRadioBearer. In another embodiment, theadditional parameters for the DAPS PDCP entity is provided by extendingPDCP-Config, which further provides the header (de)compression parameterfor the target cell, when HO command is configured with dapsConfig.

FIG. 13 shows an exemplary RRC procedure diagram to maintain two sets ofsecurity keys for both source cell and the target cell during HO inaccordance with embodiments of the current invention. In one embodiment,the UE maintains a source cell security key for transmitting andreceiving (1310) and a target cell security key for transmitting andreceiving (1320). In one embodiment for security key updating, such asin LTE, if dapsConfig is configured and the securityConfigHO is includedin the RRCConnectionReconfiguration, at step 1311, the UE continuesusing the old source keys, such as KeNB, K_(RRCint), K_(uPint),K_(RRCenc), K_(UPenc). At step 1312, the UE continues using the currentintegrity algorithm and ciphering algorithm for datatransmission/reception with the source cell. For the target cell (1320),at step 1321, the UE derives and stores a new set of keys for the targetcell. At step 1334, the UE configures the DAPS PDCP entity applying thenew keys of the target cell for the data transmission/reception to/fromthe target cell and the old keys for the source cell.

FIG. 14 illustrates an exemplary RRC procedure to release the connectionwith the source cell after HO is successfully completed in accordancewith embodiments of the current invention. At step 1401, the UE receivesthe RRC reconfiguration message includes a flag such asreleaseSourceCell to release the connection with the source cell. Atstep 1411 and step 1412, for DRB addition/modification, the UE releasesthe RLC entities and the associated logical channels of the source celland reconfigures the PDCP entity in accordance with the pdcp-Config. Foreach logicalChannelIdentity value that is to be released as the resultof source cell release, the UE releases the RLC entity or entities andreleases the corresponding logical channels. Additionally, the UEreleases RLC bearer. At step 1413, the UE reconfigure the PDCP entity inaccordance with the pdcp-Config. The PDCP reconfigures the DAPS PDCPentity to normal PDCP entity.

FIG. 15 illustrates an exemplary flow chart of a PDCP reconfiguration tochange from normal PDCP to DAPS PDCP in accordance with embodiments ofthe current invention. At step 1501, the PDCP entity receives a PDCPentity reconfiguration request from upper layers of a UE, wherein the UEis connected with a source cell in a wireless network, and wherein theUE is configured with a dual active protocol stack (DAPS) associatedwith the source cell and a data radio bearer for a target cell. At step1502, the PDCP entity establishes a header compression protocol andapplying a header compression configuration provided by upper layers forthe target cell. At step 1503, the PDCP entity establishes a cipherfunction and applying a cipher algorithm and key provided by upperlayers for the target cell. At step 1504, the PDCP entity establishes anintegrity protection function and applying an integrity protectionalgorithm and key provided by upper layers for the target cell.

FIG. 16 illustrates an exemplary flow chart of a PDCP reconfiguration tochange from DAPS PDCP to normal PDCP in accordance with embodiments ofthe current invention. At step 1601, the PDCP entity receives a PDCPentity reconfiguration request from upper layers of the UE, wherein theUE is configured with a DAPS associated with a source cell and a targetcell, and wherein a RLC entity associated with the PDCP entity isreleased for a radio bearer. At step 1602, the PDCP entity releases aheader compression protocol associated with the released RLC entity. Atstep 1603, the PDCP entity releases a cipher function associated withthe released RLC entity. At step 1604, the PDCP entity releases anintegrity protection function associated with the released RLC entity.

FIG. 17 illustrates an exemplary flow chart of an RRC reconfiguration inDAPS in accordance with embodiments of the current invention. At step1701, the UE detects a DAPS flag indicating to maintain a UP protocol ofa source cell while performing handover to a target cell in a wirelessnetwork. At step 1702, the UE creates a target MAC entity for the targetcell. At step 1703, the UE establishes a radio link control (RLC) entityto associate with (DRBs of) the target cell. At step 1704, the UEreconfigures a PDCP entity as DAPS PDCP entity. At step 1705, the UEreconfigures the PDCP entity to associate with the RLC entity associatedwith the target cell.

Although the present invention has been described in connection withcertain specific embodiments for instructional purposes, the presentinvention is not limited thereto. Accordingly, various modifications,adaptations, and combinations of various features of the describedembodiments can be practiced without departing from the scope of theinvention as set forth in the claims.

What is claimed is:
 1. A method, comprising: receiving a packet dataconvergence protocol (PDCP) entity reconfiguration request by a PDCPentity from upper layers of a user equipment (UE), wherein the UE isconnected with a source cell in a wireless network, and wherein the UEis configured with a dual active protocol stack (DAPS) associated withthe source cell and a data radio bearer for a target cell; establishinga header compression protocol and applying a header compressionconfiguration provided by upper layers for the target cell; establishinga cipher function and applying a cipher algorithm and a key provided byupper layers for the target cell; and establishing an integrityprotection function and applying an integrity protection algorithm andkey provided by upper layers for the target cell.
 2. The method of claim1, wherein the PDCP reconfiguration request is triggered by receiving ahandover command with a dapsConfig flag.
 3. The method of claim 1,further comprising: switching header compression, integrity protectionand cipher functions associated to the source cell to headercompression, integrity protection and cipher functions associated to thetarget cell upon receiving a switching request from lower layers.
 4. Themethod of claim 3, wherein lower layers send the switching request uponreceiving a first UL grant from the target cell.
 5. The method of claim1, further comprising: enabling the PDCP reordering and reordering thepackets received from both of the lower layers associated to the sourcecell and the target cell, wherein the on-going PDCP reordering procedureis not interruption and t-Reordering keeps as it is if the PDCPreordering function is used before the PDCP entity is reconfigured.
 6. Amethod, comprising: receiving a packet data convergence protocol (PDCP)entity reconfiguration request by a PDCP entity from upper layers of auser equipment (UE), wherein the UE is configured with a dual activeprotocol stack (DAPS) associated with a source cell and a target cell,and wherein a radio link control (RLC) entity associated with the PDCPentity is released for a radio bearer; releasing a header compressionprotocol associated with the released RLC entity; releasing a cipherfunction associated with the released RLC entity for the radio bearer;and releasing an integrity protection function associated with thereleased RLC entity for the radio bearer.
 7. The method of claim 6,wherein the released RLC entity is associated with the source cell. 8.The method of claim 6, further comprising: stopping and resettingt-Reordering when the PDCP entity reconfiguration request is receivedwhile a reordering function is configured.
 9. The method of claim 6,further comprising: disabling a reordering function during thereconfiguration procedure if the PDCP entity reconfiguration request isreceived while the reordering function is not configured.
 10. The methodof claim 6, wherein the PDCP reconfiguration request is triggered byreceiving a RRC reconfiguration message to release the source cell. 11.A user equipment (UE), comprising: a transceiver that transmits andreceives radio frequency (RF) signal in a wireless network; a packetdata convergence protocol (PDCP) entity that receives a PDCPreconfiguration request from upper layers of the UE, wherein the UE isconnected with a source cell in the wireless network, and wherein the UEis configured with a dual active protocol stack (DAPS) associated withthe source cell and a data radio bearer for a target cell; and a PDCPDAPS reconfiguration entity that establishes a header compressionprotocol and applies a header compression configuration provided byupper layers for the target cell, establishes a cipher function andapplies a cipher algorithm and key provided by upper layers for thetarget cell, and establishes an integrity protection function andapplies an integrity protection algorithm and key provided by upperlayers for the target cell.
 12. The UE of claim 11, wherein the PDCPreconfiguration request is triggered by receiving a handover commandwith a dapsConfig flag.
 13. The UE of claim 11, wherein the PDCP DAPSreconfiguration entity switches header compression, integrity protectionand cipher functions associated to the source cell to headercompression, integrity protection and cipher functions associated to thetarget cell upon receiving a switching request from lower layers. 14.The UE of claim 13, wherein lower layers send the switching request uponreceiving a first UL grant from the target cell.
 15. The UE of claim 13,wherein the PDCP DAPS reconfiguration entity reconfigures the PDCPentity to associate with the target cell, processes PDCP service dataunit (SDU) from upper layers, and sends PDCP packet data unit (PDU) tothe target cell upon function switch.
 16. The UE of claim 11, whereinthe PDCP DAPS reconfiguration entity enables a PDCP reordering andreorders packets received from lower layers associated to the sourcecell and the target cell.
 17. The UE claim 11, wherein the PDCP entityreceives a second PDCP entity reconfiguration request from upper layerswhen a radio link control (RLC) entity associated with the PDCP entityis released for a radio bearer, and wherein the PDCP DAPSreconfiguration entity releases a header compression protocol associatedwith the released RLC entity, releases a cipher function associated withthe released RLC entity for the radio bearer, and releases a headercompression protocol associated with the released RLC entity for theradio bearer.
 18. The UE of claim 17, wherein the released RLC entity isassociated with the source cell.
 19. The UE of claim 17, wherein the UEstops and resets t-Reordering when the second PDCP entityreconfiguration request is received while a reordering function isconfigured.
 20. The UE of claim 17, wherein the UE disable a reorderingfunction during the reconfiguration procedure if the PDCP entityreconfiguration request is received while the reordering function is notconfigured.